Hacker's Arsenal - The Cutting Edge of Hacking/Hacker's Arsenal - The Cutting Edge of Hacking.iso/texts/misc/netprobe.txt

Text File | 2001-07-11 | 10KB | 192 lines

How to Handle and Identify
Network Probes

"What to do when your DNS server gets FIN-SYN
scanned from Russia at 4:00 in the morning."

By Ron Gula
April 1999

[e-mail]
http://www.network-defense.com
Copyright 1999 Network Defense Consulting

Abstract

Do you know what to do when suspicious network probes are detected on
your network? It's surprising, but many people do not follow common
sense and simple logic when analyzing malicious network activity. Even
worse, when contacting other organizations to complain, security incidents
can be misrepresented because all of the facts are not in order, incorrect or
even erroneous theories. This paper details a variety of steps that you can
take to get the most effectiveness and accuracy from your intrusion
detection system. It also concentrates on determining the who, what, why,
where, when and how of any network security event so that you can
accurately relay this information to others.


Introduction
This paper is loosely organized into a list of rules that can be applied to
 your network operation in the event of an external network scan. Each rule
 has several examples of what can go wrong and what can go right for a given
 situation. The rules are also in the order they should be applied in a network
 security situation.
The last section discusses how to handle internal security events at a high level.
 Please use this paper as a guide. Think about it and what it means for your
 particular network. It may make the difference between deterring a network attack
 and having to respond to a network compromise.

Rule #1: Don't Panic

It's 2:00 AM. You are in a deep sleep when suddenly the phone comes to life.
 Speaking to you is a late shift network operator who is frantically describing
 a list of  ISS RealSecure events. The operator also describes that the firewalls
 are also going crazy and two NT machines just mysteriously rebooted.
 The VP of Operations has been notified and she is on her way in. What do you do?

Even though network security events are reported in the media and they are
 a very serious threat, they are not likely to occur to you on a daily basis.
 (If they are occurring to you on a daily basis you must be pretty good at
 dealing with them by now and probably don't need this paper.) Most network
 organizations that suffer multiple attacks and probes experience them in groups.
 They are not sporadic events.

With this in mind we can roughly classify network probes into two categories.
 First, the security event could actually be the result of a non-security event.
 This is known as a 'false positive'. In this case there is nothing to worry about.
 Second, the security event could be a probe that tested your site for something.
Tests could include determining the type of operating system of a server or even
 sweeping the network for open ports. If the probe turns up negative, there is a
 good chance that 'they' won't be coming back. With this situation, there is also
 little to worry about. At your leisure, you can pursue those responsible for the probe.
If the probe seems to have found something that is vulnerable, then you may
have returning visitors. Regardless of the outcome of the probe, it requires
 careful analysis and some judgement calls to determine its nature. That's what
 the rest of this paper is about.

When presented with a security event, all you really know is that further
 investigation is required. Knowing that these things don't happen that often
 shouldn't cause you to put the analysis of the event off to long though.
 Timely analysis of any security event is the key to quickly finding the real
 ones from the false positives.

Panic or at least an adrenaline rush is experienced by many network administrators
 when security incidents occur. Here are some rules of thumb to keep in mind when
 handling the situation.

Initially, only tell people about the security event on a need to know basis

Telling one person who tells another can cause any office or operations center
 to quickly fill with people who are not the right ones to deal with the problem.
 They may also get in the way. Discretion is highly recommended.

Watch out for overworked people

When any network event occurs, there is a tendency for normal people to rise
 to the challenge and work long hours to see the event through. Security events
 are no different. If an event occurs at the end of a normal duty day or a shift,
 people working extra hours may suffer from fatigue, irritability and hunger.
 All of these can impair the judgement of any human. It may also endanger them
 for their ride home. Later on we discuss the importance of documentation.
 Documentation and tracking of a security event can make change over between
 employees much easier.

Don't let people jump to conclusions

During high pressure situations, some people may feel the need to blame others
 in an attempt to find answers. It's important to downplay any of these comments
 until all of the facts are considered.

Get second opinions on 'rash' decisions

When conducting a security investigation, it is very important to get input
 from peers and even management about your current theories and plans. For example,
 it may seem like a good idea to take the corporate web server offline for analysis,
 but a second opinion might ask you to stand up a replacement. If probes are
 occurring in real time, it is also temping to take certain courses of action
 such as 'hack backs', setting up of honey-pots or even trying
 to slow the scanning down. All of these actions may have unintended
 repercussions on your company or network.

Focus on any obvious explanations

It may not seem obvious, but suspicious activity can be explained away most of
 the time with normal network events. Consider recent network changes or scheduled
 network testing when analyzing a security event.

Like it or not, as the network security guru you are also in a position of
 leadership during security events. If you are not sure of yourself, panicked
 or exhibiting a high level of stress, these traits can easily spread to other
 people. In ideal situations, the network security staff
 (if there are more than one of you) is regularly involved in network operations.
  Knowing your coworkers and making sure that they know you will reduce stress
 and panic during security events.

"Don't worry", you say to the late shift operator, "I will dial in and
 check the logs. Tell Beth I'll give her an initial status report in about
 fifteen minutes. If it looks bad, I'll be coming in."

Rule #2: Document Activity

It's Monday morning and you receive a call from the Vice President of
 Information Security. He wants to know how many network probes we have
 received over the last three months and if any of them came from our competitors.
 What would you tell him?

When any network security event occurs, you should document it. It doesn't
 matter how you record the information as long as it is secure, accurate and
 can be stored for some time. I like to keep a log book, but log books
 can be lost. Some network shops record suspicious logs directly to CD-ROM.
 More and more network shops are using ticketing systems to track security events.
 These have the advantage of existing in a database which can easily be
 searched for event correlation. You need a solution which is right for you.

Why document? There are several reasons:

People forget, even security gurus

Having a physical record of security events from days gone past is
 an immense help when analyzing security events of today and tomorrow.
 Being able to answer questions like, "Has this IP address ever scanned
 us before?", or "How many other IMAP probes have we had this year?" can
 only be answered by reviewing historical logs.

Security systems may not keep logs forever

Some security programs do not keep logs forever. They delete old logs
 to make room for new ones. If you have a system such as this, then those
 security events from last month might not be in your security system any more.
 Keeping logs separate from the production systems ensures a greater level of
 data protection also. What happens if you have a hard drive crash? Many security
 systems do not use back-ups for data
integrity.

It might be evidence in court

If you keep good logs (and good is subject to lawyer's interpretation)
 then those logs may be used as evidence in a court case. It is very
 important to keep a 'chain of evidence' with any log system. This means
 you need to have proper access control on the log information. If the
 security or integrity of the log can be questioned, then the log may not
 be admissible in court. Paper print outs and CD-ROMs tend to be more believable
 than electronic media. Even logging of DNS names instead of IP addresses
 may be an issue, since DNS name resolution can be corrupted.

It helps you sell security

If you are like most companies, network security is viewed as an
 important but expensive thing. Firewalls, intrusion detection systems
 and conferences to Black-Hat are all expensive. Keeping logs can help
 show management that there is indeed a threat and they are getting their
 money's worth from you and the fancy security equipment.

Final thoughts:

During the heat of the moment is when it is most important to write
 down or record any information about a security event. Don't forget
 to record the people involved, their phone numbers and what they have said.
 Recording all of the information allows for more efficient processing of
 the data once it is assembled together.